Release 10.1A: OpenEdge Getting Started:
Application and Integration Services

OpenEdge Adapter for SonicMQ architecture

The OpenEdge Adapter for SonicMQ consists of the following three connection modes:

OpenEdge Adapter for SonicMQ ClientConnect
OpenEdge Adapter for SonicMQ ServerConnect
OpenEdge Adapter for SonicMQ BrokerConnect

OpenEdge Adapter for SonicMQ ClientConnect

OpenEdge Adapter for SonicMQ ClientConnect (ClientConnect) architecture combines the adapter with the OpenEdge client process. ClientConnect runs as a process started and managed by OpenEdge clients directly when an application requires messaging. There is a single adapter process per client process, as shown in Figure 7–1. The SonicMQ Broker acts as a service point for all JMS sessions.

Figure 7–1: OpenEdge Adapter for SonicMQ ClientConnect architecture

Note: AdminServer and NameServer are no longer needed to connect to the OpenEdge Adapter for SonicMQ ClientConnect.

ClientConnect is a direct connection to the SonicMQ Broker, so it is not necessary to manage a server process. This connection provides complete end-to-end messaging. Additionally, ClientConnect supports JMS domain unification, client persistence, fault-tolerant connections, server-based message selectors, serialized connection objects, temporary destinations, TempTable messages, DataSet messages, and enhanced XML support. With ClientConnect, there is a direct connection between the 4GL client and the SonicMQ Broker. By eliminating the network connection between a 4GL client and the server-based OpenEdge Adapter for SonicMQ, ClientConnect provides reliable messaging all the way through to the 4GL client. This allows ClientConnect to support fault tolerance. (BrokerConnect does not support fault tolerance.)

OpenEdge Adapter for SonicMQ ServerConnect

OpenEdge Adapter for SonicMQ ServerConnect (ServerConnect) architecture combines the adapter with the OpenEdge Servers (WebSpeed and AppServer). ServerConnect runs a single adapter process per ubroker process, allowing multiple server processes to connect to this single adapter process, as shown in Figure 7–2. The SonicMQ Broker acts as a service point for all JMS sessions.

;

Figure 7–2: OpenEdge Adapter for SonicMQ ServerConnect

ServerConnect is a direct connection to the SonicMQ Broker. This connection provides complete end-to-end messaging. Additionally, ServerConnect supports JMS domain unification, client persistence, fault tolerant connections, server-based message selectors, serialized connection objects, temporary destinations, TempTable messages, DataSet messages, and enhanced XML support.

It is recommended that you use ServerConnect if your application requires several clients to access the SonicMQ messaging services.You can use particular AppServer or WebSpeed servers to manage particular SonicMQ connections, thus minimizing the number of SonicMQ connections required. The embedded process that runs inside of the AppServer or WebSpeed server is multi-threaded and allows for multiple SonicMQ connections within the same process.

Progress Explorer contains a new property page to manage the new ubroker properties required for ServerConnect. Figure 7–3 shows the new property page as it appears in the Messaging on WebSpeed and AppServer.

Figure 7–3: Progress Explorer property page

OpenEdge Adapter for SonicMQ BrokerConnect

OpenEdge Adapter for SonicMQ BrokerConnect (BrokerConnect) architecture consists of both a Server to the OpenEdge Client and a Client to the SonicMQ Broker. BrokerConnect requires the client to access the adapter container by specifying connection parameters for the controlling NameServer or OpenEdge Adapter for SonicMQ instance (if not registered with a controlling NameServer) when the JMS session is created.

Note: This differentiates the SonicMQ Broker from the AppServer or WebSpeed broker, both of which have one or more Progress agent processes running.

Each instance of BrokerConnect is a single broker process running one or more client threads (servers in the Progress Explorer), as shown in Figure 7–4. Each client thread talks to a 4GL application on one side and a SonicMQ Broker on the other side. BrokerConnect acts as the JMS client to the SonicMQ session. You can also start more than one BrokerConnect instance under a single controlling NameServer.

Figure 7–4: OpenEdge Adapter for SonicMQ BrokerConnect

BrokerConnect is not a direct connection to the SonicMQ Broker. Therefore, BrokerConnect cannot provide the Quality of Service (QOS) between a 4GL client and the SonicMQ Broker that ClientConnect and ServerConnect offer.

BrokerConnect is managed by the Progress Explorer administration framework, which includes the Progress Explorer and related command-line utilities.

BrokerConnect supports JMS domain unification, server-based message selectors, serialized connection objects, temporary destinations, TempTable messages, DataSet messages, and enhanced XML support. BrokerConnect does not support fault tolerance and client persistence.

You should use BrokerConnect if you are concerned about the size of your 4GL session or server process, or machine resources.

Note: BrokerConnect is functionally equivalent to the OpenEdge Adapter for SonicMQ architecture supported in releases earlier than Release 10.1A.

Figure 7–5 shows one possible scenario for BrokerConnect. The application does not have to be on the AppServer, and it is not generally necessary to have more than one BrokerConnect instance at a given OpenEdge installation. The only software requirement on the 4GL side is a set of r-code files that provides the 4GL-JMS API to BrokerConnect.

Figure 7–5: An example of BrokerConnect in context

In this scenario, a distributed application (an information source) is built using SmartObjects that generate information for use by other applications. In this case, the information source has a SmartProducer object on the AppServer, which uses BrokerConnect to send the information across the Internet using a SonicMQ Broker.

Elsewhere on the Internet, another application (an information user) uses the SmartConsumer object on a 4GL client to retrieve the information sent by the information source. This SmartConsumer object receives the information on behalf of the 4GL client through the information user’s own SonicMQ Broker and BrokerConnect.

The information source can be an inventory, news, stock, or any similar module that provides data, depending on the business, and of course the information user is any application that has a need for this information. The relationship between the information source and user could be Pub/Sub or PTP, depending on the requirements set up with SonicMQ by the information source and its users.

As shown in Figure 7–5, you can access BrokerConnect either directly from a 4GL application or over the Internet, using the AppServer Internet Adapter (AIA). In the scenario, the WebClient and standard 4GL client could both have access to BrokerConnect over the Internet while the AppServer running the SmartProducer is accessing the same BrokerConnect directly over an intranet connection.

Note also that in addition to the Internet connection security provided by the AIA when accessed using HTTPS, both the AIA and any 4GL application accessing BrokerConnect directly can tunnel the AppServer protocol connection to the Adapter through an OpenEdge implementation of the Secure Sockets Layer (SSL). Thus, data privacy can be provided over the entire wire from the Internet through the intranet between the client and BrokerConnect.

For more information on:

Setting up and managing BrokerConnect in any context, see OpenEdge Application Server: Administration .
Using the 4GL-JMS API in a Progress 4GL application, see OpenEdge Development: Messaging and ESB .
Using the SmartProducer and SmartConsumer objects to access BrokerConnect, see OpenEdge Development: ADM and SmartObjects .
Providing data privacy over connections between the client and BrokerConnect, see OpenEdge Getting Started: Core Business Services .